It's unfortunate that that r belongs to NodeContext. Reader.local doesn't make sense this way since the computation proceeds in a Process, not on the node itself. Perhaps it would be more adequate to move the r into ProcessEnv proper.

I believe the intent was/is for all Processes on a node to have the very same environment. One reason to have it this way is for some "global" data to be shared, especially when some kind of supervisor would be responsible for spawning Processes. If the r is not node-global, the API for such supervisor could become quite a bit more complicated, I believe.

I'd be happy to be proven wrong, though!

They can share global data if that is what's needed downstream:

host :: Process Global ()
host = do
  localData <- setup...
  spawn onlyGlobal
  withProcessEnv (const localData) $ spawn onlyLocal
  withProcessEnv (, localData) $ spawn hasBoth
  ...

hasBoth :: Process (Global, Local) ()
  globalData <- asks fst
  ...

Of course if you need common data you don't want to drop it entirely.

And Process r is a MonadReader r, so that r can be changed per-process anyway with local :: (r -> r) -> .....

So the alternative is using awkward and non-total wrappers:

data GlobalAndLocal = Both
  { common :: Int
  , specific :: Maybe Socket -- awkward
  }

data GlobalOrLocal
  = Common Int
  | Specific Socket -- oops, lost that "global node data" anyway

I will try to lift env into process and see what happens...

It was pleasantly simple. The changes got contained in the runNode entry point and the rest rides along with the usual Reader stuff. The tests pass unchanged and user-facing API kept intact.

Hmh, I still wasn't able to remember why I made everything a ReaderT (basically) with the context stored at the node level...

In any case, given the change you suggested, does Process need to be a MonadReader at all? The only reason I can think of is to emulate Erlang's process dictionary, but then it should rather be a MonadState.

Maybe there shouldn't be a default MonadReader per se, just a bunch of functions to manipulate the process environment.

A user then can easily recover MonadReader just by plugging the functions manually. Alternatively, a user can use them to weld a reader-style effect system and have their stuff in there.

MonadState most certainly should not be provided as an effect that would back it should not be hardcoded. Some processes would like IORef-backed state, but some would vie for TMVar.